Thanks for apotting that! It's been too long since I've played with Python. (Side note- that decorator trick is also really cool! It makes sense now that I've seen it, but I don't think I'd have ever thought of it myself- I probably would've ended up translating the code into a single expression)

Weird- The check-mypy failure is the same that's on main*, but the test failures are really weird, since test_swervecontrollercommand is failing from a lack of numpy, but I didn't touch any of that.

*By the way, it looks like check-mypy is failing on the return type mismatch in Command.fork() (which was added in #71 when it hadn't actually been added to WPILib - see wpilibsuite/allwpilib#7083 - and the WPILib PR went in a different direction after the robotpy-commands PR was merged) and on missing joystick.getDirectionDegrees() and joystick.getDirectionRadians(), which were deprecated in 2023 in wpilibsuite/allwpilib#5319 in favor of a unit overload and were removed in wpilibsuite/allwpilib#6569.

My impulse would be to remove Command.fork() and wait until the WPILib PR gets merged since it's quite likely the version of fork() that ends up in WPILib will be different from what's currently in robotpy-commands. However, I'm quite new to robotpy-commands and I don't know if there's other reasons to go a different route.

I'm not familiar with how Python units work (How does the pybind work with the C++ units classes?), but it looks like you can probably implement CommandJoystick.getDirectionDegrees() and CommandJoystick().getDirectionRadians() in terms of self._hid.getDirection(), but I'm not sure.

I'm not sure why I merged fork. I agree it should be removed.

Python will pass units to C++ as a float, in the unit that the function parameter is specified as. There is no mechanism to check units, but the name of the unit ends up in the .pyi typestub file for the function.

Any ideas on the dist/ci/test failures? (Example log here: https://github.com/robotpy/robotpy-commands-v2/actions/runs/12476284136/job/34841958986?pr=79)
They seem to be failing because numpy is missing, but I don't get how in the world my PR could've affected that.

By the way, it looks like check-mypy is failing on the return type mismatch in Command.fork() (which was added in #71 when it hadn't actually been added to WPILib - see wpilibsuite/allwpilib#7083 - and the WPILib PR went in a different direction after the robotpy-commands PR was merged)

Update on this- The upstream PR was just closed, so Command.fork() definitely doesn't need to exist.

They seem to be failing because numpy is missing

Hmm. I think a recent change to WPILib means wpimath.geometry.Rotation2d's constructor has a dependency on numpy now. That dependency is missing in the robotpy-wpimath package metadata.

Those bugs should now be fixed if you rebase onto main.

My bad, I forgot to pull after applying @TheTripleV's suggested change so when I rebased I accidentally dropped that commit.